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Web services have recently emerged as a 
powerful technology for integrating 
heterogeneous applications over the Internet. 
The widespread adoption of Web services 
promises to usher in an exciting new 
generation of advanced distributed applications. 
These will support a new and growing set of 
specifications, such as Simple Object Access 
Protocol (SOAP), Web Services Description 
Language (WSDL), and Universal Description, 
Discovery, and Integration (UDDI). Extensible 
Markup Language (XML) and its associated 
family of standards also play a central role in 
Web services by providing a data interchange 
format that is independent of both programming 
languages and operating systems. The 
application developer seeking to reap the 
benefits of Web services is therefore faced 
with a significant, and potentially steep, new 
learning curve. Clearly, application development 
tools that lower this barrier are crucial for the 
rapid and widespread adoption of Web 
services. This paper discusses the development 
tasks associated with XML Web services and 
describes a new suite of tools that improve 
developer productivity, by reducing the 
requirements for detailed knowledge of the 
underlying specifications and standards, and 
allow the developer to focus on the business 
problem domain. This suite of XML and Web 
services tools is part of IBM’s recently released 
WebSphere® Studio Application Developer 
product, which is based on the new Eclipse 
open source tool integration platform. 


Web services provide a distributed computing tech¬ 
nology for integrating applications over the Inter¬ 
net. Such a technology has the potential to dramat¬ 
ically transform our information-based economy. 
However, there have been many distributed comput¬ 
ing technologies in the past, for example, Common 
Object Request Broker Architecture* * (CORBA* *), 
Microsoft DCOM**, and Java** Remote Method In¬ 
vocation (rmi), yet none has become widespread on 
the Internet. Although Web services technologies are 
described in detail in the other papers of this issue 
of the IBM Systems Journal, it is useful here to briefly 
compare Web services with the other distributed 
computing technologies so that we can understand 
what they have in common and what has changed. 
Application developers who are already familiar with 
a previous distributed computing technology will be 
able to immediately apply much of their knowledge 
and experience to Web services. An overview of Web 
services 1 as well as in-depth technical information 2 
can be found on the Web. 

All distributed computing technologies, including 
Web services, provide a mechanism for a client pro¬ 
gram, executing on a local host, to invoke a server 
function that executes on a remote host and to re¬ 
ceive the result of the remote execution. The style 
used by the client program to invoke the server func¬ 
tion depends on the distributed computing technol¬ 
ogy. For example, the client program may call a re- 
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mote procedure, invoke a method on a remote 
object, or put messages on and get messages from 
a queue. These invocation styles are referred to as 
remote procedure call (RPC), Remote Method In¬ 
vocation (rmi), and message queuing. 

The programming interface supported by the remote 
server function is often specified using an interface 
definition language (idl). The IDL typically speci¬ 
fies the operations provided by the remote server 
function, their input and output parameters, and 
their exceptions. Tools are provided to generate a 
client “stub,” or proxy, and a server skeleton from 
the IDL. Although the terms stub and proxy are both 
used in practice, the term proxy is used in the fol¬ 
lowing discussion. The client proxy gives the client 
program a convenient way to invoke the remote 
server function. The server skeleton provides a place 
to include the implementation of the remote server 
function. The proxy and skeleton hide the protocol 
details from the local client program and the remote 
server function implementation. 

The local client program calls the client proxy 
through its programming language interface. The cli¬ 
ent proxy converts the programming language input 
parameters into a byte stream that can be sent to 
the remote server using some protocol and transport 
mechanism. The process of converting programming 
language parameters into a protocol-dependent byte 
stream is referred to as “marshaling.” The remote 
host routes the invocation to the correct server skel¬ 
eton, which converts the incoming byte stream back 
into programming language parameters. The pro¬ 
cesses of converting the protocol-dependent byte 
stream back into programming language parameters 
is referred to as “unmarshaling.” Marshaling and un¬ 
marshaling may also be referred to as “serialization” 
and “deserialization.” The client program and server 
skeleton may use different programming languages 
and operating systems. The server skeleton passes 
the input parameters to the function implementa¬ 
tion for execution, receives the execution result, mar¬ 
shals it into a response, and sends it back to the cli¬ 
ent proxy. The client proxy unmarshals the response 
and returns the result to the local client program. 

If Web services were simply another distributed com¬ 
puting technology, there would be little reason to 
get excited. However, there are some fundamental 
differences between Web services and its predeces¬ 
sors that make the technology very powerful. The main 
difference between Web services and the previous dis¬ 
tributed computing technologies is that they are de¬ 


signed for the extremely heterogeneous environment 
of the Internet. The Internet is composed of a huge 
number of highly diverse computers, ranging from 
the simplest client devices to the most complex main¬ 
frame servers. In addition, these computers are not 
under the control of a single information technol¬ 
ogy department that can impose uniform software 
standards. Web services specifications are therefore 
completely independent of programming language, 
operating system, and hardware, and they enforce 
very loose coupling between the client and the server. 

To see why the programming language and operat¬ 
ing system independence of Web services is a major 
advance, consider the tight coupling present in 
CORBA, Microsoft DCOM, and Java RMI. CORBA cou¬ 
ples the client and server with an underlying object 
model. In addition, the protocol used by CORBA, In¬ 
ternet Inter-ORB** Protocol (HOP**), was not ini¬ 
tially specified tightly enough to guarantee interop¬ 
eration between different vendors. More recent 
versions of HOP seek to achieve vendor interoper¬ 
ability. DCOM couples the client and server through 
the Microsoft Windows** operating system. At¬ 
tempts to implement DCOM on other operating sys¬ 
tems have not gained significant market acceptance. 
Finally, Java RMI couples the client and server 
through the Java programming language. In prac¬ 
tice, successful use of Java RMI involves even tighter 
coupling, because Java object serialization is very 
sensitive to virtual machine levels and class versions. 
CORBA, DCOM, and Java RMI are important distrib¬ 
uted programming technologies and will not be re¬ 
placed by Web services in situations where tight cou¬ 
pling is both desirable and possible. However, in 
situations that require loose coupling, Web services 
will likely become the dominant technology. 

Web services are designed for maximum interoper¬ 
ability across the Internet. Extensible Markup Lan¬ 
guage (xml ) 3 plays a key role as the main data in¬ 
terchange format for Web services parameter 
marshaling. In comparison with the highly optimized 
binary formats used by other distributed computing 
technologies, Web services may appear inefficient, 
but those technologies entailed tight coupling be¬ 
tween the client and server and would therefore 
never become dominant on the Internet. In addition, 
the continual improvements in network bandwidth, 
processor speed, and compression techniques make 
the more verbose nature of xml of less concern. 

The use of XML in Web services is a major differ¬ 
ence from other distributed computing technologies 
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and has important application development conse¬ 
quences. In the other technologies, the IDL makes 
use of data structures that correspond closely with 
the supported programming languages, often involv¬ 
ing certain assumptions about an underlying object 
model, and the data interchange format is a highly 
optimized binary stream that tightly couples the cli¬ 
ent and the server. In xml Web services, the data 
types are specified using xml Schema (xsd) 4 and 
the data interchange is in XML format. Although the 
Web services run-time environment can automati¬ 
cally encode programming language data structures 
as XML, this introduces coupling between the pro¬ 
gramming language and the Web service interface. 
Application developers will find it beneficial to de¬ 
sign interfaces using XSD in order to give them 
greater implementation flexibility. As application de¬ 
velopers begin to think in terms of XML rather than 
programming languages when defining Web services, 
they will begin to need tools for authoring XSD and 
Web Services Description Language (wsdl). 5 

As Web services are initially adopted, client proxies 
and server skeletons will normally be implemented 
in conventional programming languages, such as Java 
and JavaScript**. Tools for mapping between xml 
Schema and programming language data structures 
will be used to hide the XML details from the pro¬ 
grammer. However, as xml becomes more familiar 
to programmers, its role may broaden to also include 
processing. Examples of XML processing technology 
include Extensible Stylesheet Language Transforma¬ 
tions (xslt), 6 xml support in databases such as IBM 
Database 2* (DB2*) Universal Database (udb), 7 and 
xml Query 8 language. These technologies allow the 
programmer to specify processing natively in terms 
of xml as opposed to converting between xml and 
conventional programming languages. In many cases 
it may be more productive for programmers to spec¬ 
ify simple processing using an XML technology, and 
to call out to conventional programming languages, 
such as Java, for more complex processing. Tools for 
editing and debugging XML processing technologies 
will become important. 

In the case of Web services, the role of the interface 
definition language is played by WSDL, and although 
WSDL can in theory be extended to describe arbitrary 
transports and marshaling, the use of HyperText 
Transmission Protocol (http), Simple Object Ac¬ 
cess Protocol (soap), 9 and xml are likely to dom¬ 
inate on the Internet. Web services can also be used 
effectively for integrating applications within an en¬ 
terprise that has control over the computing infra¬ 


structure. Other transport mechanisms, such as mes¬ 
sage queuing, may be used within the corporate 
intranet. However, many enterprises have a heteroge¬ 
neous computing infrastructure that has many char¬ 
acteristics in common with the Internet. Corporate 
mergers and acquisitions are another factor that in¬ 
creases the diversity of the enterprise computing envi¬ 
ronment and that makes the use of xml Web services 
attractive. In fact, many enterprises may benefit from 
implementing Web services behind their firewall be¬ 
fore they expose them to partners and customers. 

The SOAP run-time environment 

Apache SOAP 10 is a Java Open Source implemen¬ 
tation of the SOAP specification that runs in Web¬ 
Sphere*, Apache Tomcat, 11 and other Java 2 Plat¬ 
form, Enterprise Edition (J2EE**) -compliant 
application servers. IBM SOAP adds security, admin¬ 
istration, and tracing enhancements to Apache SOAP. 
IBM SOAP is a fully supported component of Web¬ 
Sphere 4.0 that provides a production-ready envi¬ 
ronment for deploying Web services. 

Due to the rapid evolution of Web services speci¬ 
fications and implementations, developers can ex¬ 
pect to see a steady stream of new versions of Apache 
SOAP. Many developers will want to experiment with 
the latest Apache SOAP versions before they become 
part of the fully supported IBM SOAP product imple¬ 
mentation. The Web services tools described here 
therefore support deployment to both Apache SOAP 
and IBM SOAP so that developers can track the latest 
advances and be well positioned to quickly exploit 
them as soon as they become part of the supported 
production environment. 

The Apache SOAP run-time environment includes 
support for both Java clients and Java servers. A Java 
client can access SOAP Web services implemented 
in any programming language. Indeed, the power of 
Web services is that the programming language used 
to implement the service is both unknown and ir¬ 
relevant to the client. The Apache SOAP run-time 
environment has built-in support for implementing 
Web services as Java classes or scripting language 
programs and has an extension mechanism, called 
the Pluggable Provider Interface, for implementing 
other types of Web services. Providers for Enterprise 
JavaBeans** (ejb**), database stored procedures, 
and Microsoft COM objects are included with Apache 
SOAP. IBM SOAP includes a provider for DB2 XML Ex¬ 
tender, which is described later in more detail. Pro¬ 
viders allow developers to deploy existing compo- 
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nents as Web services, and to develop new Web 
services using languages other than Java. 

Java/XML type mapping. As previously discussed, 
any distributed computing technology must provide 
support for marshaling and unmarshaling data. In 
the case of Apache SOAP, the run-time component 
is implemented in Java code and the data interchange 
format is XML, so rules for specifying the mapping 
between Java and xml types must be provided as 
part of the implementation of every Java client or 
Web service. The SOAP specification includes a def¬ 
inition of the SOAP encoding style, which further 
guides the marshaling and unmarshaling process, but 
other encoding styles can be used. The Apache SOAP 
run-time environment allows the developer to spec¬ 
ify how to map between Java and xml types for a 
given encoding style. The developer can specify a se¬ 
rializer to marshal the Java type to xml, a deseri¬ 
alizer to unmarshal the XML type to Java, or both 
for two-way mapping. 

The rules for mapping between Java and XML types 
are stored in a SOAP mapping registry object that is 
used by either the Java client proxy or the Web ser¬ 
vice. The SOAP mapping registry has predefined rules 
for mapping between simple Java and xml types. 
However, if the Web service interface involves com¬ 
plex XML types, then the developer must specify how 
they are mapped to corresponding Java types. 

The simplest way to map xml types is to use the Java 
type org.w3c.dom.Element, which represents a generic 
xml element in the Document Object Model (dom). 12 
This technique is referred to as literal XML encoding. 
However, this approach requires that the developer un¬ 
derstand the details of the xml type and the Java ap¬ 
plication programming interface (API) for DOM. The 
use of Element is error prone, because the developer 
can create an invalid element, but for XML types that 
are not too complex, this may be the best approach. 

If the developer is deploying a Java class as a Web 
service, and the Java class uses a Java bean in its in¬ 
terface, then the bean can be mapped to XML using 
the SOAP encoding style. The SOAP specification de¬ 
fines how to represent programming language data 
types as xml. The Apache SOAP run-time environ¬ 
ment includes a bean serializer that implements SOAP 
encoding for Java beans. The bean serializer can mar¬ 
shal an instance of a Java bean into XML or unmar¬ 
shal xml into an instance of a Java bean. 


If the developer is proceeding from the WSDL def¬ 
inition of a Web service and its interface includes a 
complex xml type, then the xml type can be mapped 
to a custom Java class that is generated from the xml 
Schema type definition using tools provided in the 
WebSphere Studio Application Developer suite. The 
custom Java class includes methods for marshaling 
and unmarshaling. The ability to generate a Java class 
that corresponds to an xml Schema complex type 
is useful for general application development and is 
included as part of the XML Schema Editor tool, 
which is described later in greater detail. 

WebSphere Studio Application Developer 

The following sections describe application devel¬ 
opment tools for xml Web services that are included 
as part of WebSphere Studio Application Developer, 
a new integrated development environment that is 
based in the Eclipse platform. 13 Eclipse is a Java open 
source development tool integration platform that 
will provide a common environment for all future 
IBM tools. Eclipse is designed to be easily extended 
by other tool vendors and customers. An early ver¬ 
sion of Eclipse, and the tools described here, was 
released on alphaWorks* as the IBM xml and Web 
Services Development Environment. 14 In addition 
to xml and Web services tools, WebSphere Studio 
Application Developer includes a complete suite of 
tools for Java programming, Web application devel¬ 
opment, database access, ejb creation, debugging, 
tracing, and performance monitoring. 

WebSphere Studio Application Developer is a proj¬ 
ect-oriented, team-based development environment 
that allows the developer to launch editors and wiz¬ 
ards against resources. A detailed description of 
Eclipse and WebSphere Studio Application Devel¬ 
oper is beyond the scope of this paper. Instead, a 
few features of the environment are briefly described 
here. 

Figure 1 shows the workbench window, which is the 
main window in the development environment. It 
contains a set of perspectives. The developer can 
switch between perspectives by clicking on an icon 
along the left of the window or using the Perspec¬ 
tive menu. Each perspective contains a set of views 
and editors that are relevant to a particular task. The 
screenshot shows the Web perspective, which is use¬ 
ful for developing Web applications and Web 
services. Other perspectives are defined for Java pro¬ 
gramming, database development, server configu¬ 
ration, and XML development. In this perspective, 
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Figure 1 The workbench window 



editors for two resources (TernperatureConverter.java 
and TemperatureConverter.wsdl) and the Navigator, 
Outline, and Tasks views are open. The Navigator 
view displays the resources in all the development 
projects. The Outline view displays the contents of 
the currently active editor, which in this example, is 
open on a Java source file. The Tasks view displays 
problems and user-defined tasks. In this example, 
the Task view displays an error message caused by 
a missing semicolon in the open Java source file. The 
environment has a user interface style that should 
be familiar to many developers, but it is unique in 
its extensibility. Developers can not only easily de¬ 
fine new perspectives, but can also create new views 
and editors that integrate seamlessly with the envi¬ 
ronment. 


Web services development tasks 

Web services development adds several new tasks to 
the application development process. Some of these 
tasks should be familiar to those developers who have 
prior experience with other distributed programming 
technologies. It is useful to group the tasks accord¬ 
ing to the following development life-cycle activities: 

• Discover existing Web services 

• Access existing Web services and compose them 
into new applications and Web services 

• Create new Web services by using existing com¬ 
ponents or developing new components 

• Deploy new Web services into an application server 

• Test new and existing Web services 

• Publish new Web services 
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Figure 2 The UDDI Explorer 



Discover. The discover task consists of locating the 
Web services needed to build a new application or 
Web service and importing their WSDL files into the 
development project. As the number of available 
Web services increases, programmers will have trou¬ 
ble discovering them. This problem is addressed by 
the Universal Description, Discovery, and Integra¬ 
tion (uddi) business registry, 15 which indexes Web 
services so they can be discovered quickly. 

Developers can access uddi by several means, uddi 
itself is exposed as a SOAP Web service, so develop¬ 
ers can write custom applications that search UDDI 
nodes. However, this is labor-intensive and requires 
a detailed knowledge of the uddi programming in¬ 
terface. Each uddi node also offers its own Web- 
based user interface, but this user interface differs 


from node to node, depending on the operator, 16 so 
a developer who needs to search nodes from several 
operators would have to learn multiple user inter¬ 
faces. 

WebSphere Studio Application Developer includes 
the UDDI Explorer, which provides a common user 
interface to any compliant UDDI business registry. 
The UDDI Explorer is seamlessly integrated into the 
development environment and shares its common 
look and feel. The uddi Explorer lets the developer 
perform powerful queries against UDDI business reg¬ 
istries and allows the results to be filtered and viewed 
in flexible ways. Figure 2 is a screenshot of the UDDI 
Explorer. As queries are executed, the results are 
added to the uddi Navigator view and can act as the 
starting point for further queries. Working in this 
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way, the developer can navigate through the UDDI 
hierarchy to locate Web services that satisfy the ap¬ 
plication requirements. When the developer finds a 
suitable Web service, its WSDL description can be eas¬ 
ily imported into the development project where it 
can be used in further development tasks. For ex¬ 
ample, the developer can generate a sample appli¬ 
cation that allows him or her to test the Web ser¬ 
vice. The UDDI Explorer supports the recommended 
best practices for using WSDL in UDDI business reg¬ 
istries. 17 

Initially, UDDI registries were hosted only by IBM and 
Microsoft, who developed the specification. Now 
UDDI is beginning to be deployed by other organi¬ 
zations. For example, developers can find many in¬ 
teresting Web services in the UDDI registry main¬ 
tained by XMethods. 18 

Access. The access task consists of developing cli¬ 
ent code that invokes the Web service. The input to 
this task is the WSDL file that describes the Web ser¬ 
vice to be accessed. The client code may be used as 
part of a new Web application or Web service. Af¬ 
ter the client code has been developed, it can be in¬ 
corporated into the new application or Web service 
using standard programming tools such as editors, 
compilers, and debuggers. WebSphere Studio Ap¬ 
plication Developer supports Web service access 
from Java and JavaScript clients. 

JavaScript clients. A JavaScript Web service client 
would normally run in a Web browser, although desk¬ 
top JavaScript applications are also possible. Web¬ 
Sphere Studio Application Developer includes a 
JavaScript development environment that is inte¬ 
grated with the Web application development tools. 
The JavaScript development environment includes 
an editor that supports syntax highlighting and code 
completion, wizards for generating complex Java¬ 
Script code snippets, and a debugger. Support for 
JavaScript clients is important because of the wide 
adoption of JavaScript by Web application develop¬ 
ers. Many developers find JavaScript easier to use 
than Java, and for simple applications, JavaScript 
may be the best choice. 

The simplest form of JavaScript client uses the 
HTTP GET or POST Web service bindings to obtain 
an XML response for processing in the Web browser. 
This approach requires that the JavaScript client 
parse and process the xml response, perhaps using 
xslt. Web browser-based xml processing has been 


available for some time now, and this approach is 
likely to be popular due to its simplicity. 

A more sophisticated form of JavaScript client is 
based on SOAP. Microsoft Internet Explorer 5, and 
later versions, supports an HTML component, called 
the WebService Behavior, 19 which takes a WSDL file 
as input and dynamically creates a JavaScript object 
that acts as a SOAP client proxy for the Web service. 
With this approach, the developer programs directly 
in JavaScript, not XML. 

Web browser access to Web services raises security 
concerns similar to those raised by Java applets. Spe¬ 
cifically, if the Web browser allowed JavaScript code 
to access Web services located at any URL (uniform 
resource locator), then a Web page could attempt 
access to Web services located behind the firewall. 
Therefore, Web browsers are likely to restrict access 
by a Web page to those URLs that are located on the 
host that served the Web page. This means that if 
a Web page needs to compose Web services that are 
located on different hosts, then those Web services 
must be accessed indirectly by wrapping them with 
another Web service that resides on the Web page 
host and that redirects the requests. The wrapping 
Web service is in effect a server proxy. Therefore, 
Web browser access to Web services will not nec¬ 
essarily reduce the traffic on the Web page host. 
However, the benefit in creating server proxies is to 
make Web services more accessible to the very large 
community of developers who are skilled in client- 
side JavaScript programming. The restrictions on 
Web service access imposed by Web browsers can 
be entirely avoided by performing server-side access. 

Java clients. A Java Web service client would nor¬ 
mally be a server-side component such as a servlet, 
JavaServer Pages** (JSP**) Web page, Java bean, 
or ejb bean, but it could also be an applet or desk¬ 
top application. The easiest way to access a Web ser¬ 
vice from a Java client is to use the Web Service Cli¬ 
ent Wizard to generate a client proxy from the WSDL 
file. The client proxy is a Java class that has a method 
for each operation defined in the WSDL file. The sig¬ 
nature of each method matches the message parts 
for the operation. The client proxy uses the Apache 
SOAP run-time component to marshal the Java 
method arguments into XML and unmarshal the XML 
response into the Java return value. The rules for 
mapping between Java and xml are defined in a 
SOAP mapping registry object for the client. The cli¬ 
ent proxy may therefore also include custom Java 
classes that are generated by the xml Schema tools. 
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The generated Java client proxy accesses a generic 
Call object that is part of the Apache SOAP run-time 
component. The Call object takes the operation 
name and a list of arguments as input parameters, 
and can dynamically invoke the remote Web service 
operation in a way that is analogous to the way that 
ordinary Java methods can be invoked using reflec¬ 
tion. Sophisticated Java programmers may find it 
useful to access the Call object directly without the 
use of a generated client proxy. Direct access to the 
Call object allows highly dynamic applications where, 
for example, the WSDL for the Web service is ob¬ 
tained at run time. 

The Web Service Client Wizard can also generate 
and launch a sample JSP test client that lets the de¬ 
veloper immediately test the Web service and pro¬ 
vides a starting point for further development. The 
test client will be discussed later in more detail. 

Create. The create task involves creating a new Web 
service. In general, a complete Web service imple¬ 
mentation consists of a WSDL file that describes the 
service, a deployment descriptor that specifies a com¬ 
ponent that implements the service and other infor¬ 
mation, a component that implements the operations 
of the service, and associated code that performs type 
mapping or other functions. Depending on the im¬ 
plementation technology, some of these develop¬ 
ment artifacts may not be required. 

The Apache SOAP run-time environment supports 
several styles of Web service implementation based 
on traditional software components, such as Java 
beans, ejb beans, database stored procedures, and 
scripting language programs. Each of these imple¬ 
mentation styles is handled by a provider class that 
is part of an extensible framework. It is therefore 
possible to create Web services based on new types 
of components by defining an appropriate provider. 
For example, WebSphere Studio Application Devel¬ 
oper supports Web services based on DB2 xml Ex¬ 
tender, which will be described later. The provider 
type, and associated parameters such as the name 
of the component that implements the service and 
type mapping information, is defined in an Apache 
SOAP deployment descriptor, which is an XML file 
that normally uses the namespace prefix “isd.” We 
often refer to deployment descriptors as “ISD files” 
and use “isd” as the file extension. 

In addition to SOAP-based Web services, it is pos¬ 
sible to create Web services that use the http get 
and POST bindings. These non-SOAP Web services 


can be implemented by servlets, JSP Web pages, Com¬ 
mon Gateway Interface (CGi) programs, or other 
URL-addressable Web programming technologies. 

The tasks involved in creating a Web service depend 
on the starting point. The two main scenarios are 
bottom-up and top-down. In the bottom-up scenario, 
the developer first creates or reuses a component 
that implements some business function, and then 
transforms it into a Web service by creating its WSDL 
file, deployment descriptor, and any other required 
supporting code. The bottom-up approach will be 
widely used in the initial phase of Web services adop¬ 
tion, because it allows developers to reuse existing 
components. In the top-down scenario, the devel¬ 
oper first creates or is given the WSDL file for the 
service, and then must create a component to im¬ 
plement the operations. The top-down approach will 
become more important as industry groups begin to 
agree on standard WSDL interfaces to common bus¬ 
iness functions. A meet-in-the-middle approach is 
also possible. In this case the starting point consists 
of both the WSDL file and the implementation com¬ 
ponent, and the developer must create additional 
support code that maps between the two. 

WebSphere Studio Application Developer supports 
the bottom-up approach for Java beans, EJB beans, 
Structured Query Language (SQL), and URLs, and 
the top-down approach for Java beans. Over time, 
the tool coverage for the top-down, bottom-up, and 
meet-in-the-middle approaches will expand to in¬ 
clude more implementation technologies. 

All major relational database vendors are incorpo¬ 
rating XML capabilities into their products, and work 
is underway to extend the SQL standard to directly 
support XML. DB2 UDB includes the XML Extender, 
which allows XML documents to be stored in columns 
or composed and decomposed into tables as relation¬ 
al data. The mapping from XML to relational data 
is specified by an XML Document Access Definition 
(dad) file. WebSphere Studio Application Devel¬ 
oper includes the Relational Database to xml Map¬ 
per tool, which allows the developer to easily generate 
DAD files. This tool is described later in more detail. 

The support for XML in DB2 makes it a natural choice 
for implementing Web services. WebSphere Studio 
Application Developer supports the creation of Web 
services implemented in DB2 xml Extender (dxx) 
that are defined by DAD Extension (dadx) files. A 
dadx file is an xml file that contains operations de¬ 
fined by normal SQL statements and calls to the spe- 
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Table 1 Developing the Flights Web Service 


Task 

Input 

Output 

Tool 

Set up the Web application 

Add the Flights Web service 
group to the Web 
application. This group 
accesses the Airline 
database. 

web.xml 

web.xml, 
group.properties 

DADX 

Group 

Configuration 

Wizard 

Create the operation 

Create the SQL statement 
that lists the flights. This will 
become the listFlights 
operation of the Web 
service. 

Airline database 
schema 

listFlights.sqx 

SQL Query 
Builder 

Create the Web service 

Create the DADX file that 
contains the listFlights 
operation. 

listFlights.sqx 

Flights.dadx 

XML from 

SQL Query 
Wizard 

Deploy the Web service 

Deploy to the application 
server and create the WSDL. 

Flights.dadx 

Flights.isd, 

Flights.wsdl 

Web Service 
Wizard 

Test the Web service 

Create the Java client proxy 
and a JSP sample application 
to test the Web service. 

Flights.wsdl 

Flights.java, 

TestClient.jsp 

Web Service 
Client Wizard 


cial stored procedures included in DB2 XML Extender. 
IBM SOAP includes a provider for handling DADX files. 
WebSphere Studio Application Developer includes 
an SQL Builder tool that can generate DADX files. 
Developers can edit the generated DADX using a 
standard text editor or the XML Editor tool that is 
included with WebSphere Studio Application De¬ 
veloper. The SQL Builder and XML Editor tools are 
described later in more detail. 

Deploy. The deploy task consists of configuring an 
application server to run the Web service and install¬ 
ing the Web service on the application server. Web¬ 
Sphere Studio Application Developer includes server 
tools for setting up the application server. Aversion 
of WebSphere is included with the development envi¬ 
ronment and developers can also use Tomcat. The 
Web Services Wizard automatically associates an in¬ 
stance of an application server with the Web proj¬ 
ect, installs the SOAP run-time component and all 
required run-time libraries, starts the server, and de¬ 
ploys the Web service to the application server. 

The Apache SOAP run-time component manages de¬ 
ployed Web services using a pluggable configuration 


manager. The default configuration manager allows 
Web services to be deployed and removed at run 
time, and stores the list of deployed services in a se¬ 
rialized Java object that is read when the server starts. 
The Apache SOAP run-time component also has an 
XML-based configuration manager; it stores the list 
of deployed services as an xml file, which provides 
more portability. Allowing services to be freely de¬ 
ployed and removed at run time is convenient for 
developers but may not be suitable for production. 
The IBM SOAP run-time component includes a con¬ 
figuration manager suitable for production use. The 
IBM configuration manager also uses an xml file, 
dds.xml, to store the list of deployed services, and 
allows defined services to be suspended and resumed, 
but new services cannot be added at run time. The 
Web Services Wizard automatically creates dds.xml 
for the IBM configuration manager. 

Deploying DADX Web services requires a further de¬ 
velopment step. The association between a DADX 
Web service and the database it accesses is defined 
by a Web services group. Each DADX service within 
a group accesses the same database. The database 
connection information and other properties com- 
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mon to the group are specified in a standard Java 
properties file, group.properties, which is placed in 
the home directory for the group along with all the 
DADX files in the group. The DADX provider is based 
on the Web Services Object Runtime Framework 
(WORF), an IBM extension to the Apache SOAP run¬ 
time environment. WORF includes the DXX invoker 
servlet, which instantiates a subclass of the standard 
SOAP RPC router servlet. The DXX invoker servlet ex¬ 
tends the standard RPC router servlet by adding 
HTTP GET and POST bindings and automatically gen¬ 
erating WSDL and a test page for the Web service. 
An instance of the DXX invoker servlet must be added 
to the Web application for each group of DADX Web 
services. 

The task of setting up a DADX group is simplified by 
the DADX Group Configuration Wizard, which adds 
an instance of the DXX invoker servlet, creates 
the required directory structure, and writes the 
group.properties file. 

Test. The test task consists of invoking the opera¬ 
tions of a Web service to validate or understand its 
behavior. WebSphere Studio Application Developer 
supports Web service testing in several ways. As men¬ 
tioned previously, the Web Service Client Wizard 
can generate a client proxy and a sample JSP-based 
test client that accesses it. The sample test client is 
intended to act as a starting point for further devel¬ 
opment but can also be used for testing the Web ser¬ 
vice. In addition to generating a sample test client 
that uses the Java client proxy, WebSphere Studio 
Application Developer includes the Universal Test 
Client, which can dynamically test the proxy or any 
other Java class without generating any code. Finally, 
Web services deployed using the WORF extension to 
the Apache SOAP run-time environment can dynam¬ 
ically generate a test page that enables any poten¬ 
tial user of the Web service to test it from the user’s 
browser. 

Although these test methods are useful for unit test 
of the operations of a Web service, problems may 
occur at the protocol or transport level. For this class 
of problems, WebSphere Studio Application Devel¬ 
oper includes a TCP/IP (Transmission Control 
Protocol/Internet Protocol) monitor that can be used 
to inspect HTTP requests and responses. 

Publish. The publish task consists of registering a de¬ 
scription of the Web service in a UDDI business reg¬ 
istry so that it can be located by other application 
developers. The UDDI Explorer lets the developer 


Figure 3 The DADX Group Configuration Wizard 



update UDDI business registries in addition to search¬ 
ing them. The WSDL files created by WebSphere Stu¬ 
dio Application Developer follow the UDDI best prac¬ 
tices guidelines and are therefore ready to publish. 
The developer can easily publish a Web service by 
selecting its WSDL file in the navigator view and ex¬ 
porting it to UDDI. This action launches the UDDI 
Explorer. 

Updating a registry normally requires that the de¬ 
veloper register with the node operator and obtain 
a user identifier and password to be used when log¬ 
ging in. Developers can use the UDDI Explorer to 
update any UDDI business registry that they have ac¬ 
cess to. Most node operators, including IBM, provide 
a public test registry for experimentation. IBM also 
provides a private UDDI registry that developers can 
use for local testing. 

Scenario 1: Developing the Flights Web 
service 

To illustrate the preceding steps, we now describe 
a development scenario in which we create a simple 
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Figure 4 The SQL Query Builder 



Web service. The Flights Web service lists flights for 
an airline. Because it simply retrieves information, 
it is natural to implement it using a database query. 
If this Web service involved more complex business 
logic, we could have implemented it using a Java 
stored procedure, a Java class, or a session bean. Ta¬ 
ble 1 lists the main tasks involved, the input and out¬ 
put development artifacts, and the tool used to per¬ 
form the task. 

Set up the Web application. Let us assume that we 
have created a database named Airline to hold the 
flight information, and that we have created a Web 
project for developing the Web service. Our first step 
is to create a Web service group to hold the services 
that access the database. We run the dadx Group 
Configuration Wizard , as shown in Figure 3. 


The wizard prompts us for the database connection 
information and other parameters, which are stored 
in the group.properties hie in the directory created 
for the group. The wizard then updates the Web ap¬ 
plication deployment descriptor, web.xml, by adding 
an instance of the dxx invoker servlet to the Web 
service requests. 

Create the operation. The Flights Web service will 
contain a single operation, listFlights, that lists all the 
flights that leave before a specified departure time. 
In general, a Web service contains many operations 
but we use a single operation here to simplify the 
example. We use the SQL Query Builder to create the 
SQL select statement and save it to an SQL hie, 
listFlights.sqx. SQL INSERT, UPDATE, and DELETE 
statements can also be created. Figure 4 shows the 
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SQL Query Builder, which allows tables to be added 
using a drag-and-drop style user interface. 

Create the Web service. The xml from SQL Wizard 
can generate a dadx file from a set of SQL state¬ 
ments. Figure 5 shows the wizard prompting for op¬ 
eration name, descriptions, and output file name, 
which in the example is Flights. dadx. 

Figure 6 shows the generated dadx file in the xml 
Editor. The editor provides a tree-based design view 
and a text-based source view, dadx files can be mod¬ 
ified in the XML editor or any other text editor. 

Deploy the Web service. After the dadx file has 
been created, it must be deployed to the Web ap¬ 
plication server. The Web Service Wizard handles all 
deployment tasks. If the Web project is not currently 
associated with a Web application server, the wiz¬ 
ard associates the default server with the project. The 
wizard installs the SOAP run-time component the first 
time a Web service is deployed, configures an in- 


Figure 5 The XML from SQL Query Wizard 



Figure 6 The XML Editor 
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Figure 7 The Web Services Wizard 



Figure 8 The sample application 



stance of the SOAP RPC router servlet if necessary, 
generates the SOAP deployment descriptor for the 
service, and updates the deployed services config¬ 
uration file. The wizard then starts the server, gen¬ 
erates the WSDL file for the service, and adds it to 
the Web application. Figure 7 shows the first page 
of the wizard. 

Test the Web service. The Web Service Client Wiz¬ 
ard generates a Java client proxy from the WSDL for 


the service, and a JSP sample application that uses 
the proxy. Figure 8 shows the sample application that 
was generated for the Flights service. 

The sample application has a methods pane that lists 
all the operations in the service and allows us to se¬ 
lect an operation to test. We have selected the listFlights 
operation here. The inputs pane of the application 
prompts us for the input parameters of the operation. 
Here we have entered 12:00 as the departure time. The 
result pane shows the output of the operation. 

XML development tools 

XML plays two distinct roles in Web services devel¬ 
opment. The first role is that of infrastructure, in 
which XML is used for data interchange and descrip¬ 
tion. For example, messages are encoded in xml us¬ 
ing SOAP and described in XML using WSDL. In this 
infrastructure role, XML can be completely hidden 
from the developer. Web services can be developed 
in standard programming languages, such as Java, 
marshaling and unmarshaling can be handled by the 
run-time component, and the WSDL statements can 
be generated automatically and processed by tools. 

As Web services technology matures and becomes 
widely adopted, it is likely that XML will play a sec¬ 
ond role, namely that of a programming medium. 
In this programming role, developers will first be ex¬ 
posed to XML when designing Web services inter¬ 
faces in a top-down approach. Once developers be¬ 
gin to define data in terms of XML, it will be natural 
to also specify processing in terms of XML. Current 
examples of xml programming approaches include 
xslt, XML Query, and DB2 xml Extender. To use these 
new technologies, developers will require new tools. 

WebSphere Studio Application Developer includes 
an integrated suite of tools for many aspects of XML 
development, such as: 

• XML editing and validation 

• xml Schema and document type definition (dtd) 
editing and validation 

• Extensible Stylesheet Language (xsl) transforma¬ 
tion and tracing 

• Generators for creating Java beans from a DTD or 
xml Schema 

• Utilities to generate XML Schema from DTD and 
vice versa 

• Utilities to generate xml from DTD or xml Schema 
and vice versa 
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Table 2 Developing the Passenger List Web Service 


Task 

Input 

Output 

Tool 

Design the output message 
format 

Create an XML Schema to 
describe the report format. 

Convert the schema to a 

DTD for use with the DB2 

XML Extender. 


passengerList.xsd, 
passengerList.dtd 

XML 

Schema 

Editor 

Create the operation 

Map the database tables to 
the passenger list schema 
and generate a DAD file 
for the DB2 XML 

Extender. 

Airline database 
schema, 

passengerList. dtd 

passengerList.rmx, 
passengerList.dad 

RDB to 

XML 

Mapper 

Create the Web service 

Create the DADX file that 
contains the passengerList 
operation. 

passengerList.dad 

passengerList.dadx 

XML from 
SQL Query 
Wizard 

Design the user interface 

Create a sample HTML 
instance document and 
generate a DTD from it. 

Create a stylesheet to 
transform the passenger list 

XML into HTML. 

passengerList.xsd 

reporthtml.xml, 

html.dtd, 

Reportmap.xmx, 

report.xsl 

DTD Editor, 
XML to 

XML 

Mapper 

Test the user interface 

Create a sample input 
passenger list. Trace the 
execution of the stylesheet 
and generate the HTML. 

report.xsl 

passenger.xml, 

report.html 

XSL Trace 
Editor 


• Tools to integrate xml and relational data, such 
as generating XML from SQL queries 

• Utilities to generate XML schema from table def¬ 
initions and vice versa 

To illustrate how these tools can be used to create 
a new breed of Web applications based on xml Web 
services, we extend the scenario described earlier. 

Scenario 2: Developing the Passenger List 
Web service 

In this example we create the Passenger List Web 
service, which lists all the passengers that have tickets 
for a flight. This service has an operation that re¬ 
turns the passenger list for a specified flight. Here 
we take a more top-down approach by first design¬ 
ing the format of the output message as an xml 
Schema. We then map this output schema back to 


the database and express the mapping as a DAD file 
that can be executed by the DB2 xml Extender. The 
DB2 xml Extender allows us to handle xml docu¬ 
ments that have complex hierarchical structures. We 
then work on a user interface to display the output 
as HyperText Markup Language (HTML) statements. 
We create an XSL file that transforms the output 
into HTML and test its behavior using a trace tool. 
Table 2 summarizes the main tasks in this scenario 
and lists the input and output development artifacts 
and the tools used to create them. 

Design the output message format. We begin by us¬ 
ing the XML Schema Editor to create an XSD file that 
describes the passenger list format. We want the 
passenger list to include the number and departure 
time of the flight and to list the name and frequent 
flyer number for each passenger on the flight. Fig- 
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Figure 9 The XML Schema Editor 



ure 9 shows the XML Schema Editor creating 
passengerList.xsd. 

The XML Schema Editor has a design view and a 
source view. The design view presents a form-based 
user interface that is synchronized with the outline 
view. When a part of the schema is selected in the 
outline view, a form for modifying it appears in the 
design view. For example, in Figure 9 the Flight el¬ 
ement is selected in the outline view and a form for 
modifying the element is presented in the design 
view. Parts of the schema can be added and deleted 
in the outline view. The outline view and design view 
eliminate the need for a knowledge of XSD syntax, 
but developers who prefer to directly edit the file can 
work with the source view. 


In addition to the XSD Editor, WebSphere Studio 
Application Developer also has the DTD Editor. We 
refer to both XSD and DTD as schemas. WebSphere 
Studio Application Developer has extensive support 
for schemas, including tools for validating schemas, 
converting between XSD and DTD, generating sche¬ 
mas from sample XML instance documents, gener¬ 
ating sample xml instance documents from schemas, 
and generating Java classes and relational database 
schemas from XML Schema. In addition, the XML Ed¬ 
itor uses schemas to validate instance documents and 
to provide editing assistance, such as code comple¬ 
tion. 

Create the operation. Now that we have defined the 
schema for the output message, we can define the 
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Figure 10 The RDB-to-XML Mapper 



listPassenger operation that retrieves the informa¬ 
tion from the database. Here we plan to use the 
DB2 XML Extender run-time component to execute 
the query and generate the XML result. We must 
therefore define a DAD file for the retrieval oper¬ 
ation. The RDB-to-XML Mapper tool, shown in Fig¬ 
ure 10, helps us define the mapping from the data¬ 
base to the xml result. 

To define the mappings we select the column of the 
database in the tables view and its corresponding 
XML element or attribute in the XML view, and then 
add the mapping to our definition. The complete def¬ 
inition is stored in PassengerMap.rmx, which is an 
abstract representation of the mapping. The map¬ 
per generates a concrete mapping in a DAD file, 
passengerList.dad, for the DB2 XML Extender. 


The RDB-to-XML Mapper is based on a general-pur¬ 
pose mapping framework. Mapping between differ¬ 
ent data descriptions is a common application de¬ 
velopment task. For example, the XML-to-XML 
Mapper is also based on this framework. Other ex¬ 
amples include mapping between programming lan¬ 
guage data structures, for example, from COBOL to 
Java, and from xml to Java. 

Create the Web service. The DB2 xml Extender 
provides stored procedures that can execute DAD 
files. Here we want to create a Web service so, as 
before, we run the XML-from-SQL Wizard to gen¬ 
erate a DADX file, passengerList.dadx, but instead 
of referencing SQL statements we reference the 
passengerList.dad file. In general, a DADX file can 
be built from a collection of many SQL statements 
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Figure 11 The Web service test page 



and DAD files. The wizard generates both a retrieval 
operation, listPassenger, and a storage operation, up- 
datePassenger. The storage operation takes an XML 
passenger list document as input and updates the da¬ 
tabase tables. To complete the Web service, we man¬ 
ually edit the DADX file to include a flight number 
input parameter for the retrieval operation. 

We then deploy the DADX file as before using the 
Web Services Wizard, but instead of generating a 
Java client proxy and JSP sample application to test 
the new Web service, we use the WORF run-time com¬ 
ponent to dynamically generate a test and documen¬ 
tation page. Figure 11 shows the dynamically gen¬ 
erated test page for the passengerList service. 

As in the sample JSP test application, the dynamically 
generated test page is also divided into three panes. 
The methods pane lists the operations in the Web 
service and lets us select one. The inputs pane is a 
form for the input parameters of the selected op¬ 
eration, and the results pane shows the xml result 
of the operation. 

Design the user interface. Although the output of 
a Web service is normally consumed by an applica¬ 
tion for further processing, in some cases it is useful 
to format the output for presentation to users. In 


this example, we want to present the passenger list 
in a Web browser. We begin by manually creating 
a sample output HTML file, reporthtml.ximl, and use 
the DTD Editor to generate a DTD, html.dtd, from 
reporthtml.xml. Then we use the XML-to-XML Mapper 
tool to define the mapping from the XML passenger 
list schema, passengerList.xsd, to the HTML page, 
reporthtml.xml. Figure 12 shows the XML-to-XML 
Mapper. 

Here we use the mapper to define the correspon¬ 
dence between a source schema and a target sample 
instance document. We can also use a schema as the 
target of the mapping. The reason for using a sam¬ 
ple document as the target, rather than a schema, 
is that the full schema for HTML is very complex. It 
is easier to create a sample of the desired HTML out¬ 
put than to work with the complete HTML schema. 
Note, however, that mapper requires that the sam¬ 
ple HTML document be a valid XML document. 

The user interface of this mapper is similar to that 
of the RDB-to-XML Mapper because they are based 
on the same mapper framework. The abstract map¬ 
ping is stored in the Reportmap.xmx file. The map¬ 
per can generate the XSTL file, report.xsl, from the 
abstract mapping. The xslt file can be applied to 
the XML passenger list either on the server, for ex¬ 
ample in a Java servlet, or in the client, using Java¬ 
Script, if the browser supports XML parsing and XSLT. 

Test the user interface. We complete the testing of 
the user interface by running the XSL file against a 
sample passenger list file using the XSL Trace Editor, 
as shown in Figure 13. 

We generate the sample input file, passenger.xml, 
by running the Web service and saving the result. 
To run the XSL Trace Editor, we select the sample 
file, passenger.xml, and the XSLT file, report.xsl, in 
the navigator view, then invoke the trace from the 
context menu. The trace editor presents the input 
xml, the input XSL, and the output HTML. We can 
replay the transform using stepping controls in the 
toolbar. As the transform is applied, the trace ed¬ 
itor highlights each XSL statement and the XML in¬ 
put element it matches, allowing us to understand 
the transform and resolve any problems. We save 
the output as report.html. At this point we are con¬ 
fident that the XSLT file is performing as required. 
To complete development, we must incorporate the 
XSLT file into our application. 
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Figure 12 The XML-to-XML Mapper 



Conclusion 

XML Web services provide a powerful new technol¬ 
ogy for integrating heterogeneous applications over 
the Internet. WebSphere 4.0 provides a fully sup¬ 
ported production-ready deployment environment 
for Web services based on the Apache SOAP run-time 
environment. XML plays a central role by providing 
a data interchange format that is independent of pro¬ 
gramming languages, operating systems, and hard¬ 
ware. As Web services become more widely adopted, 
XML will also be used more frequently to specify pro¬ 
cessing using technologies such as XSLT, DB2 XML Ex¬ 
tender, and XML Query. 

WebSphere Studio Application Development is 
a new development environment that supports 


the full life cycle for Web services development 
with support for SOAP, WSDL, and UDDI, and 
includes a powerful suite of XML tools. Using this 
environment, developers can easily transform 
existing components, such as Java beans, EJB 
beans, and SQL statements, into Web services, and 
can incorporate Web services into new applica¬ 
tions. 

This paper has described an initial set of Web ser¬ 
vices and XML development tools. Armed with this 
information, developers should be able to begin Web 
services development using WebSphere Studio Ap¬ 
plication Developer. Over time, developers can ex¬ 
pect to see wider coverage of the development pro¬ 
cess and better integration of the tool suite for this 
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Figure 13 The XSL Trace Editor 



exciting and rapidly maturing distributed program¬ 
ming technology. 

Trademark or registered trademark of International Business 
Machines Corporation. 
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